<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<!--
Generated from $Fink: porting.fr.xml,v 1.13 2007/02/23 22:04:55 rangerrick Exp $
-->
<title>Fink Documentation - Portage de logiciel sur Darwin et Mac OS X</title></head><body>
<table width="100%" cellspacing="0">
<tr valign="bottom">
<td align="center">
Available Languages:  | 
<a href="porting.en.html">English</a> | 
Fran&ccedil;ais | 
<a href="porting.ja.html">&#26085;&#26412;&#35486; (Nihongo)</a> | 
<a href="porting.zh.html">&#20013;&#25991; (&#31616;) (Simplified Chinese)</a> | 
</td>
</tr>
</table>
<h1 style="text-align: center;">Portage de logiciel sur Darwin et Mac OS X</h1>
<p>Ce document contient quelques conseils pour réaliser le portage d'applications Unix vers Darwin et Mac OS X. Ces informations s'appliquent aux systèmes d'exploitation Mac OS X versions 10.x.x et Darwin "pur". Nous ferons référence aux deux systèmes sous le nom de Darwin, puisque Mac OS X est, en fait, un sur-ensemble de Darwin.</p>
<h2>Contents</h2><ul><li><a href="#basics"><b>1 Notions de base</b></a><ul><li><a href="#basics.heritage">1.1 D'où vient Darwin ?</a></li><li><a href="#basics.compiler">1.2 Le compilateur et les outils</a></li><li><a href="#basics.host-type">1.3 Le type de la machine hôte</a></li><li><a href="#basics.librairies">1.4 Librairies</a></li><li><a href="#basics.other-sources">1.5 Autres sources d'information</a></li></ul></li><li><a href="#shared"><b>2 Code partagé</b></a><ul><li><a href="#shared.lib-and-mod">2.1 Librairies partagées ou modules chargeables</a></li><li><a href="#shared.version">2.2 Numérotation de version</a></li><li><a href="#shared.cflags">2.3 Options de compilation</a></li><li><a href="#shared.build-lib">2.4 Construction d'une librairie partagée</a></li><li><a href="#shared.build-mod">2.5 Construction d'un module</a></li></ul></li><li><a href="#libtool"><b>3 GNU libtool</b></a><ul><li><a href="#libtool.situation">3.1 État des lieux</a></li><li><a href="#libtool.patch-135">3.2 Rustine 1.3.5</a></li><li><a href="#libtool.fixing-14x">3.3 Adaptation de la version 1.4.x</a></li><li><a href="#libtool.notes">3.4 Notes supplémentaires</a></li></ul></li><li><a href="#preparing-10.2"><b>4 Préparation pour la version 10.2</b></a><ul><li><a href="#preparing-10.2.bash">4.1 Shell bash</a></li><li><a href="#preparing-10.2.gcc3">4.2 Compilateur gcc3</a></li></ul></li><li><a href="#preparing-10.3"><b>5 Préparation pour la version 10.3</b></a><ul><li><a href="#preparing-10.3.perl">5.1 Perl</a></li><li><a href="#preparing-10.3.typedef">5.2 Nouvelles définitions de symboles</a></li><li><a href="#preparing-10.3.system-libs">5.3 Nouvelles librairies systèmes incorporées</a></li></ul></li><li><a href="#preparing-10.4"><b>6 Préparation pour la version 10.4</b></a><ul><li><a href="#preparing-10.4.perl">6.1 Perl</a></li><li><a href="#preparing-10.4.typedef">6.2 Nouvelles définitions de symboles</a></li><li><a href="#preparing-10.4.system-libs">6.3 Nouvelles librairies système intégrées</a></li></ul></li></ul><h2><a name="basics">1 Notions de base</a></h2>


<h3><a name="basics.heritage">1.1 D'où vient Darwin ?</a></h3>
<p>Darwin est un système d'exploitation de type Unix qui est issu de NeXTStep/OpenStep. La tradition veut qu'il fut initialement créé à partir de la version 4.4BSD Lite. L'héritage du système BSD est encore apparent ; en fait Darwin a été modernisé, récemment, avec du code FreeBSD et NetBSD.</p>
<p>Le noyau Darwin est construit sur une combinaison de Mach 3.0 et de BSD, ainsi que sur des fonctionnalités propriétaires comme la couche de pilote orientée objet IOKit. Bien que Mach ait, au départ, une structure de micro-noyau, le noyau BSD qui est installé au-dessus est monolithique, et les deux sont si imbriqués maintenant que l'on peut considérer l'ensemble comme un seul noyau monolithique.</p>
<p>Les outils utilisateur et les librairies fournies avec Darwin sont, pour la plupart, issues de BSD par opposition à ceux de Linux qui sont des outils GNU. Toutefois, Apple n'est pas aussi strict que d'autres systèmes BSD et a fait des compromis utiles. Par exemple, Apple fournit aussi bien make BSD que make GNU, la commande make de GNU étant celle installée par défaut.</p>

<h3><a name="basics.compiler">1.2 Le compilateur et les outils</a></h3>

<p>En bref : le compilateur est un dérivé de gcc, mais installé en tant que <tt style="white-space: nowrap;">cc</tt> ; vous pouvez avoir besoin de faire des rustines sur des Makefiles. La plupart des paquets ne construiront pas de librairies partagées. Si vous voyez des erreurs relatives à des macros, utilisez l'option <tt style="white-space: nowrap;">-no-cpp-precomp</tt>.</p>
<p>En détail : le chaînage des outils de compilation des Mac OS X Developer Tools est une drôle de bête. Le compilateur est basé sur la suite gcc 2.95.2, avec des modifications pour gérer le langage Objective C et quelques bizarreries de Darwin. Le préprocesseur (<tt style="white-space: nowrap;">cpp</tt>) existe en deux versions. L'une correspond au précompilateur standard (issu de gcc 2.95.2), l'autre est un précompilateur spécial écrit par Apple, avec gestion des headers précompilés. Ce dernier est celui utilisé par défaut, car il est plus rapide. Toutefois, certains codes ne compilent pas avec le précompilateur Apple, c'est pourquoi vous devez vous servir de l'option <tt style="white-space: nowrap;">-no-cpp-precomp</tt> pour utiliser le précompilateur standard. (Note : je recommandais, auparavant, l'option <tt style="white-space: nowrap;">-traditional-cpp</tt>. La sémantique de cette option a légèrement changé avec GCC 3, empêchant la compilation de la plupart des paquets qui l'utilise. <tt style="white-space: nowrap;">-no-cpp-precomp</tt> a l'effet désiré aussi bien sur les Developer Tools actuels que sur les futurs compilateurs basés sur GCC 3).</p>
<p>L'assembleur est soi-disant basé sur gas 1.38. L'éditeur de liens n'est pas basé sur les outils GNU. Cela pose problème lorsqu'on construit des librairies partagées, étant donné que GNU libtool et les scripts de configuration qu'il génère ne savent pas comment se comporter avec l'éditeur de liens d'Apple.</p>

<h3><a name="basics.host-type">1.3 Le type de la machine hôte</a></h3>

<p>En bref : si configure échoue avec un message d'erreur 'Can't determine host type' - Impossible de déterminer le type d'hôte, copiez config.guess et config.sub, situés dans /usr/share/libtool (/usr/libexec pour des versions antérieures au 10.2), dans le répertoire courant.</p>
<p>En détail : le monde GNU utilise un format canonique pour spécifier les types de systèmes. Ce format comporte trois parties : le type de la cpu, le fabricant et le système d'exploitation. Parfois, une quatrième partie est ajoutée - dans ce cas la troisième partie indique le noyau, tandis que la quatrième indique l'OS. Toutes les parties sont en minuscules et sont concaténées en utilisant des tirets. Quelques exemples : <tt style="white-space: nowrap;">i586-pc-linux-gnu</tt>, <tt style="white-space: nowrap;">hppa1.1-hp-hpux10.20</tt>, <tt style="white-space: nowrap;">sparc-sun-solaris2.6</tt>. Le type d'hôte pour Mac OS X 10.0 est <tt style="white-space: nowrap;">powerpc-apple-darwin1.3</tt>. Pour Mac OS X 10.2, le type d'hôte a la forme <tt style="white-space: nowrap;">powerpc-apple-darwin6.x.0</tt>, et pour Mac OS X 10.3 la forme <tt style="white-space: nowrap;">powerpc-apple-darwin7.x.0</tt>, où "x" dépend de la version exacte du système opératoire.</p>
<p>De nombreux paquets utilisant autoconf doivent connaître le type d'hôte du système sur lesquels ils sont compilés. (Note subsidiaire : il existe, en fait, trois types - hôte, build et cible - pour pouvoir gérer la compilation croisée et le portage. En général, ils sont tous les trois identiques). Vous pouvez soit passer le type d'hôte en paramètre au script configure, soit laisser le script déterminer le type d'hôte.</p>
<p>Le script configure utilise deux autres scripts pour déterminer les types d'hôtes. <tt style="white-space: nowrap;">config.guess</tt> essaie de deviner le type d'hôte, <tt style="white-space: nowrap;">config.sub</tt> est utilisé pour valider et donner une forme canonique au type d'hôte. Ces scripts sont maintenus en tant qu'entités séparées, mais sont inclus dans tout paquet qui les utilise. Naguère encore, ces scripts ignoraient totalement Darwin ou Mac OS X. Si vous êtes en présence d'un paquet qui ne reconnaît pas Darwin, vous devez remplacer les config.guess et config.sub inclus dans le paquet. Heureusement, Apple a placé des versions fonctionnelles de ces scripts dans /usr/share/libtool (/usr/libexec pour pre-10.2 OS), il vous suffit donc de les recopier à partir de là.</p>
<p>Si vous construisez un paquet Fink, vous pouvez utiliser les champs <tt style="white-space: nowrap;">UpdateConfigGuess</tt> et / ou <tt style="white-space: nowrap;">UpdateConfigGuessInDirs</tt> dans le fichier <tt style="white-space: nowrap;">.info</tt> de description du paquet, de façon à ce que la mise à jour soit automatique.</p>

<h3><a name="basics.librairies">1.4 Librairies</a></h3>

<p>En bref : vous pouvez tranquillement supprimer <tt style="white-space: nowrap;">-lm</tt> des Makefiles, mais vous n'y êtes pas obligé.</p>
<p>En détail : Mac OS X ne possède pas de librairies libc, libm, libcurses, libpthread, etc... séparées. Elles font toutes parties intégrantes de la librairie système, libSystem. (Dans les versions antérieures, c'était la structure System). Toutefois, Apple a placé des liens symboliques dans /usr/lib, donc l'édition de liens avec <tt style="white-space: nowrap;">-lm</tt> fonctionne. La seule exception est <tt style="white-space: nowrap;">-lutil</tt>. Sur d'autres systèmes, libutil contient des fonctions relatives aux pseudo-terminaux et à la gestion des ouvertures de connexion. Ces fonctions font partie de libSystem, mais il n'y a pas de lien symbolique pour fournir libutil.dylib.</p>

<h3><a name="basics.other-sources">1.5 Autres sources d'information</a></h3>

<p>Une autre source d'information pour le portage est le Wiki <a href="http://www.metapkg.org/wiki"> MetaPkg Wiki</a>.</p>
<p>Vous pouvez aussi lire la note technique d'Apple <a href="http://developer.apple.com/technotes/tn2002/tn2071.html">TN2071</a> : "Porting Command Line Unix Tools to Mac OS X" sur le portage d'outils Unix en ligne de commande sous Mac OS X.</p>

<h2><a name="shared">2 Code partagé</a></h2>


<h3><a name="shared.lib-and-mod">2.1 Librairies partagées ou modules chargeables</a></h3>

<p>Une caractéristique de Mach-O, qui surprend beaucoup de gens, est la distinction stricte entre les librairies partagées et les modules chargeables dynamiquement. Sur les systèmes ELF, cette distinction n'existe pas ; n'importe quelle partie de code partagé peut être utilisée comme librairie ou chargée dynamiquement. Utilisez <tt style="white-space: nowrap;">otool -hv <b>un_certain_fichier</b></tt> pour connaître le type de fichier de <tt style="white-space: nowrap;">un_certain_fichier</tt>.</p>
<p>Les librairies partagées de Mach-O ont un type de fichier MH_DYLIB et une extension <tt style="white-space: nowrap;">.dylib</tt>. Elles peuvent être liées avec les options statiques habituelles de l'éditeur de liens, par exemple <tt style="white-space: nowrap;">-lfoo</tt> pour libfoo.dylib. Toutefois, elles ne peuvent pas être chargées en tant que modules. (Note subsidiaire : les librairies partagées peuvent être chargées dynamiquement par le biais d'une API. Néanmoins, cette API est différente de l'API pour les lots et sa sémantique la rend inutilisable pour une émulation <tt style="white-space: nowrap;">dlopen()</tt>. En particulier, les librairies partagées ne peuvent être déchargées).</p>
<p>Les modules chargeables sont appelés "lots" dans le jargon Mach-O. Ils ont un type de fichier MH_BUNDLE. Ils peuvent avoir n'importe quelle extension, car aucun des éléments concernés n'en tient compte. Apple recommande l'extension <tt style="white-space: nowrap;">.bundle</tt>, mais la plupart des logiciels portés utilisent <tt style="white-space: nowrap;">.so</tt> au nom de la compatibilité. Les lots peuvent être chargés dynamiquement et déchargés via les API dyld, et il existe une interface qui émule <tt style="white-space: nowrap;">dlopen()</tt> au sommet de l'API. Il est impossible de lier des lots comme s'ils étaient des librairies partagées. Toutefois, il est possible de lier un lot avec des librairies partagées réelles ; celles-ci sont automatiquement chargées lorsque le lot est chargé.</p>

<h3><a name="shared.version">2.2 Numérotation de version</a></h3>

<p>Sur un système ELF, les numéros de versions sont, en général, ajoutés au nom de la librairie partagée, après l'extension, par exemple : <tt style="white-space: nowrap;">libqt.so.2.3.0</tt>. Sur Darwin, les numéros de version sont placés entre le nom de la librairie et l'extension, par exemple : <tt style="white-space: nowrap;">libqt.2.3.0.dylib</tt>. Notez que cela vous permet de demander une version spécifique de librairie à l'édition de liens, en utilisant <tt style="white-space: nowrap;">-lqt.2.3.0</tt> dans l'exemple ci-dessus.</p>
<p>Lorsque vous créez une librairie partagée, vous pouvez indiquer un nom à utiliser lors de la recherche de la librairie à l'exécution. C'est une pratique usuelle et cela permet d'installer plusieurs versions majeures d'une librairie en même temps. C'est ce qu'on appelle le <tt style="white-space: nowrap;">soname</tt> sur les systèmes ELF. Sur Darwin, la différence est que vous pouvez (et devez) indiquer le chemin complet en même temps que le nom du fichier. Ceci élimine la nécessité des options "rpath" et du système de cache ldconfig/ld.so.cache. Pour utiliser une librairie qui n'est pas encore installée, vous pouvez définir la valeur de la variable d'environnement DYLD_LIBRARY_PATH ; voir la man page dyld pour de plus amples informations.</p>
<p>Le format Mach-O permet aussi un vrai contrôle du numéro de version mineure, inconnu sur les systèmes ELF. Chaque librairie Mach-O portent deux numéros de versions : une version "courante" et une version "compatible". Les deux numéros de versions sont constitués de trois chiffres séparés par des points, par exemple 1.4.2. Le premier chiffre ne peut être nul. Les second et troisième peuvent être omis, ils ont alors la valeur zéro. Quand aucune version n'est spécifiée, le numéro par défaut est 0.0.0, ce qui est une sorte de valeur passe-partout.</p>
<p>La version "courante" n'est donnée qu'à titre d'information. La version "compatible" sert au contrôle décrit ci-après. Quand un exécutable est lié, le numéro de version de la librairie est copié dans l'exécutable. Lorsque l'exécutable est lancé, le numéro de version copié dans l'exécutable est comparé à celui de la librairie utilisée. dyld génère une erreur d'exécution et arrête l'exécution du programme, sauf si le numéro de version de la librairie utilisée est égal ou supérieur à celui utilisé durant l'édition de liens.</p>

<h3><a name="shared.cflags">2.3 Options de compilation</a></h3>

<p>Par défaut, Darwin génère du code indépendant de la position (PIC). En fait, le code PowerPC est indépendant de la position par construction, si bien qu'il n'y a ni perte de place, ni dégradation de performance. Vous n'avez donc pas besoin de spécifier l'option PIC lors de la compilation d'une librairie partagée ou d'un module. Toutefois, l'éditeur de liens n'admet pas les symboles "common" dans les librairies partagées, si bien que vous devez utiliser l'option de compilation <tt style="white-space: nowrap;">-fno-common</tt>.</p>

<h3><a name="shared.build-lib">2.4 Construction d'une librairie partagée</a></h3>

<p>Pour construire une librairie partagée, vous invoquez le compilateur avec l'option <tt style="white-space: nowrap;">-dynamiclib</tt>. Voici un exemple qui permettra de mieux comprendre le processus. Nous allons construire une librairie appelée libfoo, composée des fichiers sources <tt style="white-space: nowrap;">source.c</tt> et <tt style="white-space: nowrap;">code.c</tt>. Le numéro de version est 2.4.5, où 2 est le numéro de révision majeure (changement d'API incompatible), 4 est le numéro de révision mineure (compatible avec un retour à une API antérieure) et 5 est le compteur de révision des bogues (on l'appelle parfois une "mini-révision", elle indique des changements totalement compatibles avec l'API). La librairie ne dépend d'aucune autre librairie partagée et sera installée dans <tt style="white-space: nowrap;">/usr/local/lib</tt>.</p>
<pre>cc -fno-common -c source.c
cc -fno-common -c code.c
cc -dynamiclib -install_name /usr/local/lib/libfoo.2.dylib \
 -compatibility_version 2.4 -current_version 2.4.5 \
 -o libfoo.2.4.5.dylib source.o code.o
rm -f libfoo.2.dylib libfoo.dylib
ln -s libfoo.2.4.5.dylib libfoo.2.dylib
ln -s libfoo.2.4.5.dylib libfoo.dylib</pre>
<p>Observez quelles sont les parties du numéro de version qui sont utilisées et où elles le sont. Lors de l'édition de lien avec cette librairie, on utilise normalement le drapeau <tt style="white-space: nowrap;">-lfoo</tt>, qui donne accès au lien symbolique <tt style="white-space: nowrap;">libfoo.dylib</tt>. Quel que soit le lien symbolique ou le fichier utilisé, c'est le <tt style="white-space: nowrap;">nom_d'installation</tt> qui est écrit dans le programme. Cela signifie que l'on peut supprimer le lien symbolique "de plus haut niveau" (celui qui est le moins spécifique d'une version donnée) <tt style="white-space: nowrap;">libfoo.dylib</tt> après compilation. Lors d'une mise à jour mineure, on change juste la cible du lien symbolique <tt style="white-space: nowrap;">libfoo.2.dylib</tt> utilisé par l'éditeur de lien dynamique.</p>

<h3><a name="shared.build-mod">2.5 Construction d'un module</a></h3>
<p>Pour construire un module chargeable, vous invoquez le compilateur avec l'option <tt style="white-space: nowrap;">-bundle</tt>. Si le module utilise des symboles provenant du programme hôte, vous aurez à spécifier <tt style="white-space: nowrap;">-undefined suppress</tt> pour autoriser des symboles non définis, ainsi que <tt style="white-space: nowrap;">-flat_namespace</tt>, indispensable avec le nouvel éditeur de liens de Mac OS X 10.1. Petit exemple explicatif :</p>
<pre>cc -fno-common -c source.c
cc -fno-common -c code.c
cc -bundle -flat_namespace -undefined suppress \
 -o mymodule.so source.o code.o</pre>
<p>Remarquez qu'aucun numéro de version n'est utilisé. Il est possible, en théorie, d'en utiliser un, mais, en pratique, cela ne présente aucun intérêt. Notez aussi qu'il n'y a pas de restriction de nom pour les lots. Quelques paquets placent un "lib" avant le nom, parce que certains systèmes l'exigent ; cela ne présente aucun risque, car le programme utilise le nom de fichier complet lors du chargement du module.</p>

<h2><a name="libtool">3 GNU libtool</a></h2>



<p>Les paquets GNU qui construisent des librairies utilisent GNU libtool pour masquer les procédures de construction et d'installation de librairie dépendantes des plate-formes.</p>

<h3><a name="libtool.situation">3.1 État des lieux</a></h3>
<p>Grosso modo, on trouve quatre variantes de libtool :</p>
<ul>
<li><p><b>libtool 1.3</b> : la plus courante. La dernière version de cette branche est la 1.3.5. Elle ignore Darwin et ne construit que des librairies statiques. On la reconnaît à la présence des fichiers <tt style="white-space: nowrap;">ltconfig</tt> et <tt style="white-space: nowrap;">ltmain.sh</tt> dans l'arborescence du source.</p></li>
<li><p><b>libtool 1.4</b> : longtemps en chantier et récemment publiée en tant que nouvelle version stable, cette branche intègre mieux autoconf. Malheureusement, cela rend difficile la migration des paquets qui utilisent la version 1.3. Elle gère Darwin 1.3 / Mac OS X 10.0 sans problème et nécessite une petite rustine pour fonctionner avec Mac OS X 10.1. Elle se distingue par l'absence de <tt style="white-space: nowrap;">ltconfig</tt>. Les versions 1.3b et 1.3d sont des versions de développement de la branche 1.4 et doivent être utilisées avec prudence.</p></li>
<li><p><b>Les branches multilangages</b> : aussi appelée MLB, cette version de libtool était dans une branche de développement parallèle et gérait C++ et Java (via gcj). Elle est maintenant intégrée dans la branche de développement principale. Les versions récentes gèrent Darwin 1.3 et Mac OS X 10.0 sans modification. La MLB se reconnaît à la présence des fichiers <tt style="white-space: nowrap;">ltcf-c.sh</tt>, <tt style="white-space: nowrap;">ltcf-cxx.sh</tt> et <tt style="white-space: nowrap;">ltcf-gcj.sh</tt>.</p></li>
<li><p><b>La branche de développement actuelle</b> : c'est la version de développement qui sera un jour publiée en tant que libtool 1.5. Elle résulte de la fusion de la version 1.4 et de la MLB. Elle gère C, C++ et Java (via gcj). Malheureusement, il est difficile de la distinguer de la version 1.4, vous devez tester le numéro de version dans <tt style="white-space: nowrap;">ltmain.sh</tt>.</p></li>
</ul>
<p>En conclusion, libtool 1.3.x et les paquets qui l'utilisent (c'est le cas de la majorité des paquets utilisant libtool) nécessitent une rustine pour construire des librairies partagées sur Darwin. Apple inclut une version modifiée de libtool 1.3.5 dans Mac OS X, mais, dans la plupart des cas, elle ne fonctionne pas correctement. Christoph Pfisterer a amélioré cette version modifiée pour coder en dur le chemin correct et utiliser le numéro de version complet. Les changements ont été incorporés en amont dans les versions définitives et les versions de développement à partir de la version 1.4. Les membres de l'équipe Fink continuent à réaliser des améliorations et à les faire parvenir aux mainteneurs de libtool. Le modèle de numérotation des versions est compatible pour toutes les versions de libtool.</p>
<p>Note subsidiaire : la librairie libltdl, incluse dans toutes les versions de libtool, ne fonctionne sur Darwin que si dlcompat est installé. Elle est incluse dans Mac OS X à partir de la version 10.3. Pour les versions antérieures, on peut installer la famille de paquets "dlcompat"</p>

<h3><a name="libtool.patch-135">3.2 Rustine 1.3.5</a></h3>
<p>Si vous construisez vous-même la version 1.3.5, vous devrez appliquer cette <a href="http://www.finkproject.org/files/libtool-1.3.5-darwin.patch">rustine</a> <b>[mise à jour du 09/06/2002]</b> au source de libtool 1.3.5, puis supprimer les fichiers <tt style="white-space: nowrap;">ltconfig</tt> et <tt style="white-space: nowrap;">ltmain.sh</tt>. (Ils seront recréés à partir des fichiers .in adéquats lorsque vous lancerez configure et make). Ceci est fait automatiquement, d'ailleurs, dans le paquet actuel libtool 1.3.5 de Fink.</p>
<p>Mais ce n'est que la moitié du travail - chaque paquet utilisant libtool contient ses propres copies de <tt style="white-space: nowrap;">ltconfig</tt> et <tt style="white-space: nowrap;">ltmain.sh</tt>. Si bien que vous devez les remplacer dans chaque paquet que vous voulez construire en tant que librairie partagée. Notez que vous devez le faire avant de lancer le script configure. Vous pouvez récupérer les deux fichiers ici : <a href="http://www.finkproject.org/files/ltconfig">ltconfig</a> (98 ko) et <a href="http://www.finkproject.org/files/ltmain.sh">ltmain.sh</a> (110 ko) <b>[tous deux mis à jour au 09/06/2002]</b>.</p>

<h3><a name="libtool.fixing-14x">3.3 Adaptation de la version 1.4.x</a></h3>
<p>Il y a au moins trois versions différentes de libtool 1.4.x en usage à l'heure actuelle (1.4.1, 1.4.2, ainsi que des versions de développement plus récentes). Elles posent toutes problème avec Darwin, cependant les modifications à effectuer diffèrent selon la version. Le paquet "libtool 1.4" fourni via Fink possèdent déjà toutes les rustines nécessaires. Cependant, il vous faudra encore modifier vous-même les fichiers <tt style="white-space: nowrap;">ltmain.sh</tt> et <tt style="white-space: nowrap;">configure</tt> des paquets concernés pour qu'ils fonctionnent correctement.</p>
<ol>
<li>
<b>Le bogue du flat_namespace</b> : ce problème ne survient que si vous utilisez libtool sur Mac OS X10.1 ou une version plus récente. Dans ce cas, libtool tente d'utiliser l'option <tt style="white-space: nowrap;">-undefined suppress</tt> pour autoriser les symboles non définis, mais ne spécifie pas, en même temps, l'option <tt style="white-space: nowrap;">-flat_namespace</tt>. À partir de la version 10.1, cela ne fonctionne plus. La rustine à appliquer est de la forme :
<pre>
diff -Naur gdk-pixbuf-0.16.0.old/configure gdk-pixbuf-0.16.0.new/configure
--- gdk-pixbuf-0.16.0.old/configure	Wed Jan 23 10:11:48 2002
+++ gdk-pixbuf-0.16.0.new/configure	Thu Jan 31 03:19:54 2002
@@ -3334,7 +3334,7 @@
 ;;
 
 darwin* | rhapsody*)
-    allow_undefined_flag='-undefined suppress'
+    allow_undefined_flag='-flat_namespace -undefined suppress'
 # FIXME: Relying on posixy $() will cause problems for
 #        cross-compilation, but unfortunately the echo tests do not
 #        yet detect zsh echo's removal of \ escapes.
</pre>
</li>
<li>
<b>Le bogue du module chargeable</b> : ce bogue est provoqué par le comportement non-standard de zsh (qui est le shell par défaut dans les versions 10.0 et 10.1 ; à partir de la version 10.2, il est remplacé par bash). Le comportement non standard de zsh en matière d'utilisation des guillemets empêche de construire correctement des modules chargeables ; ce sont des librairies qui sont construites à la place (et, à la différence de ce qui se passe sur Linux, ce sont des choses réellement différentes sur Darwin). La rustine à appliquer pour résoudre ce problème ( tronquée, donc inutilisable sans modification) est de la forme :
<pre>
diff -Naur gnome-core-1.4.0.6.old/configure gnome-core-1.4.0.6.new/configure
--- gnome-core-1.4.0.6.old/configure	Sun Jan 27 08:19:48 2002
+++ gnome-core-1.4.0.6.new/configure	Fri Feb  8 01:10:21 2002
@@ -4020,7 +4020,7 @@
 # FIXME: Relying on posixy $() will cause problems for
 #        cross-compilation, but unfortunately the echo tests do not
 #        yet detect zsh echo's removal of \ escapes.
-    archive_cmds='$nonopt $(test "x$module" = xyes &amp;&amp; echo -bundle || echo -dynamiclib) ...'
+    archive_cmds='$nonopt $(test x$module = xyes &amp;&amp; echo -bundle || echo -dynamiclib) ...'
 # We need to add '_' to the symbols in $export_symbols first
 #archive_expsym_cmds="$archive_cmds"' &amp;&amp; strip -s $export_symbols'
 hardcode_direct=yes
</pre>
<p>Ce problème est résolu dans certaines versions de libtool postérieures à la 1.4.2.</p>
</li>
<li>
<b>Le bogue d'accès aux librairies utilitaires</b> : dans certains cas, libtool n'arrive pas à faire l'édition de liens avec les librairies utilitaires. Il génère alors des messages d'erreur "multiple definitions". Il semble que ceci soit causé par un problème plus fondamental dans libtool. Pour l'instant vous pouvez utiliser ce palliatif (qui supprime les symptômes mais non le problème, bien qu'il soit efficace). Merci à Dave Vasilevsky :
<pre>
--- ltmain.sh.old       2002-04-27 00:01:23.000000000 -0400
+++ ltmain.sh   2002-04-27 00:01:45.000000000 -0400
@@ -2894,7 +2894,18 @@
if test -n "$export_symbols" &amp;&amp; test -n "$archive_expsym_cmds"; then
eval cmds=\"$archive_expsym_cmds\"
else
+         save_deplibs="$deplibs"
+         for conv in $convenience; do
+       tmp_deplibs=
+       for test_deplib in $deplibs; do
+         if test "$test_deplib" != "$conv"; then
+           tmp_deplibs="$tmp_deplibs $test_deplib"
+         fi
+       done
+       deplibs="$tmp_deplibs"
+         done
eval cmds=\"$archive_cmds\"
+         deplibs="$save_deplibs"
fi
save_ifs="$IFS"; IFS='~'
for cmd in $cmds; do
</pre>
</li>
<li>
<b>Le bogue DESTDIR</b> : certains paquets, qui définissent DESTDIR et utilisent libtool 1.4.2, ont des problèmes de réédition de liens. On trouvera une discussion sur ces problèmes dans les messages ci-dessous :
<p><a href="http://mail.gnu.org/archive/html/libtool/2002-04/msg00019.html">http://mail.gnu.org/archive/html/libtool/2002-04/msg00019.html</a></p>
<p><a href="http://mail.gnu.org/archive/html/libtool/2002-04/msg00021.html">http://mail.gnu.org/archive/html/libtool/2002-04/msg00021.html</a></p>
<p><a href="http://mail.gnu.org/archive/html/libtool/2002-04/msg00025.html">http://mail.gnu.org/archive/html/libtool/2002-04/msg00025.html</a>,</p>
<p>et la rustine pour résoudre ce problème est le sujet de ces messages :</p>
<p><a href="http://mail.gnu.org/archive/html/libtool/2002-04/msg00043.html">http://mail.gnu.org/archive/html/libtool/2002-04/msg00043.html</a>.</p>
</li>
</ol>

<h3><a name="libtool.notes">3.4 Notes supplémentaires</a></h3>
<p>Pour plus d'informations sur libtool lui-même et ce qu'il fait, consultez <a href="http://www.gnu.org/software/libtool/libtool.html">la page de libtool</a>.</p>
<p>Note subsidiaire : les Developer Tools d'Apple contiennent un programme appelé, lui aussi, libtool, qui est utilisé par le compilateur pour construire des librairies partagées.
Cependant, cet outil n'a rien à voir avec GNU libtool. L'outil GNU libtool qu'Apple fournit est installé sous le nom de <tt style="white-space: nowrap;">glibtool</tt>. Ceci peut être réalisé en configurant GNU libtool avec <tt style="white-space: nowrap;">--program-transform-name=s/libtool/glibtool/</tt>.</p>

<h2><a name="preparing-10.2">4 Préparation pour la version 10.2</a></h2>


<h3><a name="preparing-10.2.bash">4.1 Shell bash</a></h3>
<p>Fink a fait la transition de OS X 10.0 à OS X 10.1 facilement, et cela, en partie, grâce à la planification des changements à faire. Nous essayerons de faire de même pour la prochaine transition, mais peu de détails nous sont connus pour l'instant.</p>
<p> Nous savons que OS X 10.2 utilisera bash au lieu de zsh dans le but de fournir la fonctionnalité <tt style="white-space: nowrap;">/bin/sh</tt>. Ceci a au moins trois conséquences pour Fink.</p>
<ul><li>Dans le passé, certains paquets de Fink créaient un CompileScript (ou un PatchScript, ou un InstallScript) qui ne faisait rien, simplement en mettant un point virgule dans le script. Ceci ne fonctionne pas avec bash et doit être remplacé par :
<pre>
CompileScript: echo "nothing to do"
</pre>
</li>
<li>Dans le passé, certains paquets de Fink utilisaient la construction <tt style="white-space: nowrap;">lib(foo|bar).dylib</tt> pour faire référence à deux librairies simultanément ; ceci ne fonctionne pas avec bash (et l'alternative <tt style="white-space: nowrap;">lib{foo,bar}.dylib</tt> ne fonctionne pas avec zsh). La solution : écrire les noms intégralement.</li>
<li>Avec bash, une rustine de libtool est nécessaire dans de nombreux cas, pour éviter que les librairies ne soient construites sans numéro de version. <b> Note : vous n'avez pas besoin de cette rustine avec libtool-1.3.5, par exemple, si vous utilisez UpdateLibtool: True </b>. Le symptôme : quand vous construisez sous bash, vous voyez :
<pre>
../libtool: test: too many arguments
</pre>
Quand cela arrive, <tt style="white-space: nowrap;">configure</tt> contient ce qui suit :
<pre>
archive_cmds='$CC $(test .$module = .yes &amp;&amp; echo -bundle || echo 
-dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts 
-install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != 
x0.0 &amp;&amp; echo $verstring)'
</pre>
Voici une rustine (mais elle doit être appliquée avec précaution, car quelquefois il y a aussi d'autres problèmes avec libtool, si bien que cette rustine doit être appliquée à la main) :
<pre>
diff -Naur gdk-pixbuf-0.16.0/configure gp-new/configure
--- gdk-pixbuf-0.16.0/configure 2002-01-22 20:11:48.000000000 -0500
+++ gp-new/configure    2002-05-10 03:02:44.000000000 -0400
@@ -3338,7 +3338,7 @@
# FIXME: Relying on posixy $() will cause problems for
#        cross-compilation, but unfortunately the echo tests do not
#        yet detect zsh echo's removal of \ escapes.
-    archive_cmds='$CC $(test .$module = .yes &amp;&amp; echo -bundle || echo 
-dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts 
-install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != 
x0.0 &amp;&amp; echo $verstring)'
+    archive_cmds='$CC $(test .$module = .yes &amp;&amp; echo -bundle || echo 
-dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts 
-install_name $rpath/$soname $tmp_verstring'
# We need to add '_' to the symbols in $export_symbols first
#archive_expsym_cmds="$archive_cmds"' &amp;&amp; strip -s $export_symbols'
hardcode_direct=yes
diff -Naur gdk-pixbuf-0.16.0/ltmain.sh gp-new/ltmain.sh
--- gdk-pixbuf-0.16.0/ltmain.sh 2002-01-22 20:11:43.000000000 -0500
+++ gp-new/ltmain.sh    2002-05-10 03:04:49.000000000 -0400
@@ -2862,6 +2862,11 @@
if test -n "$export_symbols" &amp;&amp; test -n "$archive_expsym_cmds";
then
eval cmds=\"$archive_expsym_cmds\"
else
+         if test "x$verstring" = "x0.0"; then
+           tmp_verstring=
+         else
+           tmp_verstring="$verstring"
+         fi
eval cmds=\"$archive_cmds\"
fi
IFS="${IFS=     }"; save_ifs="$IFS"; IFS='~'
</pre>
</li>
</ul>

<h3><a name="preparing-10.2.gcc3">4.2 Compilateur gcc3</a></h3>
<p>Mac OS X 10.2 utilise le compilateur gcc3.</p>
<p>Certains paquets qui ont des modules chargeables et qui utilisent libtool échouent avec une erreur install_name, car libtool passe le drapeau -install_name même avec le drapeau -bundle (alors que cela n'est pas strictement nécessaire). Ce comportement était accepté par le compilateur gcc2 mais n'est plus accepté maintenant par le compilateur gcc3. Vous trouverez la rustine <a href="http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg02025.html">ici</a>. Notez que vous n'avez pas besoin de cette rustine si votre paquet utilise libtool-1.3.5 (par exemple, si vous utilisez <tt style="white-space: nowrap;">UpdateLibtool: True</tt>) puisque elle a déjà été insérée dans une version révisée du fichier ltconfig 
(accessible dans des préversions de fink).</p>
<p>Un autre problème avec le compilateur gcc3 est l'incompatibilité pour les ABI C++ entre gcc2 et gcc3. En pratique, ceci signifie que les programmes C++ compilés avec gcc3 ne peuvent être liés à des librairies compilées avec gcc2.</p>

<h2><a name="preparing-10.3">5 Préparation pour la version 10.3</a></h2>


<h3><a name="preparing-10.3.perl">5.1 Perl</a></h3>
<p>Sous Mac OS X 10.2, <tt style="white-space: nowrap;">/usr/bin/perl</tt> correspondait à la version 5.6.0 de perl et l'architecture était représentée par la chaîne de caractères "darwin". Sous Mac OS X 10.3, <tt style="white-space: nowrap;">/usr/bin/perl</tt> correspond à la version 5.8.1 de perl, et l'architecture est représentée par la chaîne de caractères "darwin-thread-multi-2level". Ces changements n'affectent <b>probablement</b> pas l'utilisation courante de l'exécutable perl lors de la création de paquets, car chaque exécutable perl sait où trouver ses propres modules. Les mainteneurs de paquets de module perl ("-pm") qui suivent les <a href="http://www.finkproject.org/packaging/policy.php#perlmods">règles d'empaquetage des modules perl</a> en vigueur et celles des scripts <tt style="white-space: nowrap;">CompileScript</tt> et <tt style="white-space: nowrap;">InstallScript</tt> n'ont pas de souci à se faire.</p>

<h3><a name="preparing-10.3.typedef">5.2 Nouvelles définitions de symboles</a></h3>
<p>À partir de Mac OS X 10.3, il existe une définition complète du type <tt style="white-space: nowrap;">socklen_t</tt> type. Pour l'utiliser, il faut ajouter au programme :</p>
<pre>
#include &lt;sys/types.h&gt;
#include &lt;sys/socket.h&gt;
</pre>

<h3><a name="preparing-10.3.system-libs">5.3 Nouvelles librairies systèmes incorporées</a></h3>
<p>Mac OS X 10.3 comprend plusieurs librairies qui n'existaient pas dans les versions précédentes du système, et étaient donc fournies en tant que paquets Fink. Il s'agit de :</p>
<table border="0" cellpadding="0" cellspacing="10"><tr valign="bottom"><th align="left">Librairies</th><th align="left">Notes</th></tr><tr valign="top"><td>libpoll</td><td>
<p>Les fichiers <tt style="white-space: nowrap;">/usr/lib/libpoll.dylib</tt> et <tt style="white-space: nowrap;">/usr/include/poll.h</tt> sont toujours inclus, toutefois l'implémentation de cette librairie sous Mac OS X n'est pas complète. Si elle correspond à vos besoins, vous pouvez supprimer les dépendances des paquets Fink "libpoll" et "libpoll-shlibs". Le code de la librairie est incorporé dans libSystem ; cette librairie est toujours liée automatiquement. Cela signifie que le drapeau <tt style="white-space: nowrap;">-lpoll</tt> n'est pas nécessaire si vous désirez utiliser l'implémentation Mac OS X. Sachez que Mac OS X fournit un fichier <tt style="white-space: nowrap;">libpoll.dylib</tt> ; il se peut donc que <tt style="white-space: nowrap;">-lpoll</tt> donne un résultat différent selon que le paquet Fink "libpoll" est installé ou non.</p>
</td></tr><tr valign="top"><td>libdl</td><td>
<p>Les fichiers <tt style="white-space: nowrap;">/usr/lib/libdl.dylib</tt> et <tt style="white-space: nowrap;">/usr/include/dlfcn.h</tt> sont inclus maintenant ; il n'y a donc plus besoin de dépendre des paquets Fink "dlcompat", "dlcompat-dev" et "dlcompat-shlibs". Le code de la librairie est incorporé dans libSystem ; cette librairie est toujours liée automatiquement. Cela signifie que le drapeau <tt style="white-space: nowrap;">-ldl</tt> n'est plus nécessaire (mais son utilisation n'a aucun effet).</p>
</td></tr><tr valign="top"><td>GNU getopt</td><td>
<p>Cette librairie, qui comprend la fonction <tt style="white-space: nowrap;">getopt_long()</tt>, a été incorporée dans libSystem et <tt style="white-space: nowrap;">/usr/include/getopt.h</tt> ; vous n'avez donc pas besoin d'utiliser les paquets Fink "libgnugetopt" et "libgnugetopt-shlibs". Comme libSystem est automatiquement liée et que le répertoire <tt style="white-space: nowrap;">/usr/include</tt> fait partie des répertoires automatiques de recherche des headers, vous pouvez supprimer tous les drapeaux <tt style="white-space: nowrap;">-lgnugetopt</tt> et <tt style="white-space: nowrap;">-I/sw/include/gnugetopt</tt> qui avaient été ajoutés pour permettre d'accéder au paquet Fink "libgnugetopt".</p>
</td></tr></table>
<p>Lors de la migration d'un paquet vers Mac OS X 10.3, essayez de supprimer ces dépendances obsolètes, car il se peut que ces paquets soient supprimés des arborescences futures. Cela signifie qu'il faut un fichier de description différent pour chaque arborescence. Comme toujours, le champ <tt style="white-space: nowrap;">Revision</tt> doit être incrémenté lors de changements faits sur un paquet. De cette façon, les utilisateurs qui passent de Mac OS X 10.2 à Mac OS X 10.3 voient les paquets spécifiques à la branche 10.3 comme "plus récents" que les paquets de l'arborescence 10.2. Par convention, le champ <tt style="white-space: nowrap;">Revision</tt> doit être incrémenté de 10 unités lors d'une migration vers un arbre plus récent de façon à laisser une marge pour pouvoir mettre à jour les paquets des branches moins récentes.</p>
<p>Lors du test d'un paquet en migration, n'oubliez pas de désinstaller les paquets que vous avez supprimé du champ <tt style="white-space: nowrap;">BuildDepends</tt>, pour éviter que le compilateur lie avec les librairies Fink installées.</p>

<h2><a name="preparing-10.4">6 Préparation pour la version 10.4</a></h2>


<h3><a name="preparing-10.4.perl">6.1 Perl</a></h3>
<p><tt style="white-space: nowrap;">/usr/bin/perl</tt> correspond maintenant à perl 5.8.6 ; la couche architecturale est toujours "darwin-thread-multi-2level".</p>

<h3><a name="preparing-10.4.typedef">6.2 Nouvelles définitions de symboles</a></h3>
<p>Dans Mac OS X 10.4, de nombreux symboles ont changé de types. Si vous aviez précédemment défini un type explicitement, comme, par exemple, <tt style="white-space: nowrap;">socklen_t</tt> en tant que <tt style="white-space: nowrap;">int</tt>, cette définition risque de ne plus être correcte.</p>

<h3><a name="preparing-10.4.system-libs">6.3 Nouvelles librairies système intégrées</a></h3>
<p>La fonction <tt style="white-space: nowrap;">poll()</tt> dans Mac OS X 10.3 n'était qu'une émulation reposant sur <tt style="white-space: nowrap;">select()</tt>. Sous Mac OS X 10.4, <tt style="white-space: nowrap;">poll()</tt> est une vraie fonction implantée dans le noyau, mais elle est boguée lorsqu'elle est utilisée avec des sockets. Il vaut mieux l'ignorer complètement. On a appliqué sur le paquet glib2 de Fink une rustine qui permet d'utiliser une émulation complètement fonctionnelle. Vous ne courez donc aucun risque à utiliser l'implantation de fonctions similaires à poll de cette librairie.</p>

<hr><h2>Copyright Notice</h2><p>Copyright (c) 2001 Christoph Pfisterer,
Copyright (c) 2001-2011 The Fink Project.
You may distribute this document in print for private purposes,
provided the document and this copyright notice remain complete and
unmodified. Any commercial reproduction and any online publication
requires the explicit consent of the author.</p><hr>
<p>Generated from <i>$Fink: porting.fr.xml,v 1.13 2007/02/23 22:04:55 rangerrick Exp $</i></p></body></html>
